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(54) Universal data mapping system 

(57) A universal mapping system, including appara- 
tuses and methods, which is configurable through use 
of selectable configuration files to perform the bi-direc- 
tional mapping and conversion of data between different 
data structures and formats. Each configuration file 
uniquely corresponds to a particular type of device 
which stores mappable data in a structure and/or format 
different than those of other types of devices. The uni- 
versal mapping system is operable to perform mappings 
of data according to priority rules which are definable in 



the configuration files and which govern the order in 
which the mappings of data elements are performed. 
The universal mapping system is also adapted to main- 
tain associations between data elements resulting from 
prior mappings. Additionally, the universal mapping sys- 
tem is operable to persist unmappable data from a 
source during a mapping in one direction and to return 
the unmappable data to that source during a subse- 
quent mapping in the opposite direction. 
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Description 

[0001] This invention relates, generally, to the fields 
of data mapping and data synchronization, and in its 
preferred embodiment, to the mapping of personal in- 5 
formation management data which is synchronized in a 
client/server environment. 

[0002] For a number of years, computer software ven- 
dors have offered "personal information management" 
software for operation on networked and standalone 
computers. The personal information management soft- 
ware enables a user of the software to enter, edit, man- 
age, store, and retrieve "personal information" includ- 
ing, for example: names, telephone and facsimile num- 
bers, street and email addresses, and other data asso- 
ciated with contacts; appointments; "to do" lists; and, 
various other types and forms of information. Such com- 
puter software has served users well, but over the past 
few years, there has been tremendous growth in the 
manufacture and use of hand-held devices equipped 
with software which, generally, enable their users to per- 
form substantially similar tasks while unconnected or 
untethered to a traditional computer. The hand-held de- 
vices (e.g., including, but not limited to, wireless tele- 
phones, personal data assistants ("PDAs"), hand-held 
computers, portable computers, and pagers) were, and 
continue to be, made by a number of different manufac- 
turers and, as a consequence, store data representative 
of such personal information in a number of different 
structures and formats. 

[0003] Because the hand-held devices enable the en- 
try, editing, managing, storing, and retrieving of personal 
information in an, essentially, "off-line" manner, users of 
the hand-held devices often experienced difficulty in 
maintaining synchronization and consistency of person- 
al information stored on the hand-held devices with per- 
sonal information stored, for instance, on a computer at 
their offices. The computer software vendors, recogniz- 
ing the presence of this difficulty, developed synchroni- 
zation computer software which aided users of such 
hand-held devices in maintaining the synchronization 
and consistency of personal information stored on their 
hand-held devices with personal information stored on 
the users' office or other computers. The synchroniza- 
tion software substantially resolved the synchronization 
difficulties experienced by many users of hand-held de- 
vices. Unfortunately, the synchronization software re- 
quired the use of a physical communication connection 
(e.g., a cable) between a respective hand-held device 
and an office or other computer to enable the transfer 
of data representative of the personal information ("per- 
sonal information data") in an appropriate direction (i.e., 
to/from the hand-held device), Also, from the software 
vendor's perspective, the development and mainte- 
nance of such software was made difficult by the variety 
of different data formats and protocols used by the hand- 
held devices to store and communicate the personal in- 
formation data. 



[0004] Today, SyncML has emerged and serves as 
the "standard" protocol for communicating and synchro- 
nizing personal information between computers and 
hand-held devices. SyncML provides common formats 
for the exchange of personal information management 
("PIM") data between such computers and hand-held 
devices, including the "vCard" format for contact data 
and the "vCalendar" format for events (i.e., appoint- 
ments or other scheduled events) and tasks. However, 
the synchronization software vendors are still faced with 
difficulties created by the multitude of different data for- 
mats used by server computers, standalone computers, 
and hand-held devices to store personal information. 
For instance, for each contact, a PIM database on a 
server computer may have two, thirty character-long 
fields for the storage of a contact's address, while a first 
hand-held device may have one, fifty character-long 
field for storage of the contact's address and a second 
hand-held device, of a different type than the first hand- 
held device, may have three, twenty character-long 
fields for storage of the contact's address. Also, each of 
the server computer and hand-held devices may allow 
the storage of certain characters and disallow the stor- 
age of other characters in a unique manner. Additionally, 
each of the hand-held devices may map their PIM data 
to/from the vCard format, and its properties, in different 
ways. As a consequence, to enable the communication 
and subsequent synchronization of PIM data between 
the server computer's PIM database and the hand-held 
devices' PIM data stores, the different numbers and for- 
mats of fields must be mapped and/or converted to/from 
the vCard format by a server computer based, at least, 
upon on the direction of the transfer of PIM data, on the 
number and formats of the fields for data storage em- 
ployed by the server and hand-held devices, on the al- 
lowed/disallowed characters, and on the manner in 
which the different hand-held devices map their PIM da- 
ta to/from the vCard format. 

[0005] The majority of synchronization software ven- 
dors handle such requisite mapping and conversion of 
PIM data in their software by employing a set of software 
drivers which are specifically written and tailored to map 
and convert PIM data to/from the hand-held devices 
supported by their synchronization software. Because 
of the differences in the manners in which each type of 
hand-held device may store and, otherwise, handle PIM 
data, the synchronization software must, generally, in- 
clude a software driver for each type of hand-held de- 
vice. The development of such software drivers requires 
the analysis of the PIM data store structures of each type 
of hand-held device and the mappings between their da- 
ta fields and the vCard and server PIM data structures, 
the design of appropriate driver software, the implemen- 
tation (i.e., programming or coding) of the driver soft- 
ware, and the testing of the driver software. Hence, the 
development of such software drivers requires the ex- 
penditure of substantial resources in terms of time and 
money and may be fraught with potential errors. 
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[0006] Therefore, there is a need in the industry for a 
mapping system for use in conjunction with contact or 
personal information synchronization that enables the 
mapping and conversion of personal information be- 
tween a server PIM database, the data stores of differ- 5 
ent types of hand-held devices, and vCards which ad- 
dresses these and other related, and unrelated, short- 
comings. 

[0007] Broadly described, the present invention com- 
prises a universal mapping system, including appara- 
tuses and methods, which is configurable through the 
use of selectable configuration files to perform the bi- 
directional mapping and conversion of data between dif- 
ferent data structures and formats. Each configuration 
file corresponds, in a one-to-one relationship, to a type 
of device which stores mappable data in a structure and/ 
or format different than those of other types of devices. 
The universal mapping system is operable to perform 
mappings of data in accordance with priority rules which 
are definable in the configuration files and which govern 
the order in which the mappings of data elements (i.e., 
properties and/or fields) are performed. The universal 
mapping system is also adapted to maintain, in subse- 
quent mappings, associations between data elements 
resulting from prior mappings. Additionally, the universal 
mapping system is operable to persist unmappable data 
from a source during a mapping in one direction and to 
return the unmappable data to that source during a sub- 
sequent mapping in the opposite direction. 
[0008] More narrowly described, the present inven- 
tion comprises a universal mapping system, including 
apparatuses and methods, which maybe utilized, in one 
form, as a portion of a synchronization system for the 
synchronization of personal information management 
data between a server computer system and a plurality 
of client devices of different types. The universal map- 
ping system is configurable to enable the bi-directional 
mapping and conversion of personal information man- 
agement data which is stored on the server computer 
system in a first structure and/or format and on the client 
devices in different structures and/or formats which are 
unique to each particular type of client device. Prefera- 
bly, the personal information management data includes 
contact information which is exchanged between the 
server computer system and the client devices in ac- 
cordance with the SyncML protocol and the vCard for- 
mat. Because each type of client device, generally, 
maps data to/from the vCard format in a different man- 
ner, the universal mapping system includes a configu- 
ration file for each type of supported client device. Each 
configuration file may be identified and selected for use, 
during a synchronization session, based on the type of 
client device which is exchanging contact information 
with the server computer system. Generally, each con- 
figuration file includes information which identifies map- 
pings and/or priority rules for mapping data between the 
vCard format and the data structure and formats of a 
database of contact information of the server computer 



system. Also, each configuration file may include infor- 
mation which defines characters that may be allowed or 
disallowed on a corresponding type of client device, 
supply substitute characters to be used in place of the 
disallowed characters, defines maximum field sizes, 
and provides configuration values relevant to the map- 
ping and/or conversion of data. 
[0009] The universal mapping system further com- 
prises a universal mapping program having various soft- 
ware components and data objects which are operable, 
in cooperation, to configure the universal mapping pro- 
gram for operation during a synchronization session 
based upon the information present in an identified con- 
figuration file (i.e., sometimes also referred to herein as 
a "PIM specification file"). The universal mapping pro- 
gram is operable to read and interpret the information 
present in the identified configuration file and to con- 
struct and destruct, as necessary, programmatic ele- 
ments (i.e., sometimes also referred to herein as "con- 
figuration element handlers") which process particular 
types of configuration file information and which build 
other programmatic elements to perform the actual 
mapping and/or conversion, if necessary, of vCard prop- 
erties and parameters to/from data fields and values 
present in the server computer system's database de- 
pending on the direction of the synchronization session. 
Each mapping programmatic element (i.e., sometimes 
also referred to herein as a "vCard property mapper") 
is, generally, responsible for mapping a particular vCard 
property according to information in the identified con- 
figuration file. The mapping programmatic elements are 
adapted to first determine whether the vCard property 
for which they are responsible has been previously 
mapped to/from the server computer system's database 
during a previous synchronization and/or mapping ses- 
sion. If so, the prior mapping is maintained during sub- 
sequent sessions unless overridden by new configura- 
tion file information. The mapping programmatic ele- 
ments are then operable to map the vCard property for 
which they are responsible to/from field(s) of the server 
computer system's database in accordance with priority 
rules which may be present in configuration file informa- 
tion. The priority rules may define at least: sub-type, or 
one-to-one mappings, of a combination of vCard prop- 
erty parameters to/from one system database field; 
type, or one-to-many, mappings of vCard property pa- 
rameters to/from a group of system database fields; 
and, characteristic mappings of vCard property param- 
eters to/from many groups of system database fields 
and/or many specific system database fields. The map- 
ping programmatic elements are also adapted to store 
the associations of vCard properties and system data- 
base fields made during new mappings for use in sub- 
sequent synchronization and/or mapping sessions to 
maintain prior mappings. Further, the mapping program- 
matic elements are operable, after performing new map- 
pings, to store unmappable vCard properties during a 
mapping from a vCard to the system's database and to 
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return the unmappable data during a subsequent map- 
ping from the system's database to a vCard. 
[0010] The universal mapping system, during opera- 
tion according to various methods of the present inven- 
tion, receives the name or other identifier of a configu- 
ration file which is to be employed for the mapping of 
contact information between a vCard associated with a 
particular type of client device and the server computer 
system's database. After receiving the name of the con- 
figuration file, the universal mapping program parses in- 
formation present in the identified configuration file and, 
based at least upon the information, dynamically con- 
structs, destructs, and executes programmatic ele- 
ments appropriate which process particular types of 
configuration file information, build appropriate mapping 
programmatic elements, and define the sequence in 
which the mapping programmatic elements are to be ex- 
ecuted in order to achieve the mappings specified by 
the identified configuration file. Following the defined se- 
quence, the universal mapping program causes the ex- 
ecution of each of the mapping programmatic elements. 
Each mapping programmatic element initially attempts 
to retrieve historical mapping information stored in prior 
synchronization and/or mapping sessions and, if found, 
maintains prior mappings by mapping the vCard prop- 
erty for which it is responsible to/from the appropriate 
server computer system's database field(s) according 
to the historical mapping information. Then, if no histor- 
ical mapping information is found, each mapping pro- 
grammatic element maps the vCard property for which 
it is responsible to/from the appropriate server computer 
system's database field(s) following priority rules 
present in the identified configuration file or default rules 
present elsewhere. Upon performing such a new map- 
ping, each mapping programmatic element stores the 
mapping association made between the vCard property 
and the server computer system's database field(s) as 
historical mapping information for use during a subse- 
quent synchronization and/or mapping session. If, for 
some reason, it is not possible for a mapping program- 
matic element to map the vCard property for which it is 
responsible to an appropriate field(s) of the server com- 
puter system's database, the mapping programmatic el- 
ement stores the unmappable vCard property parame- 
ters) and, during a subsequent synchronization and/or 
mapping session to update contact information at the 
client device, inserts the unmappable vCard property 
parameter(s) into a vCard communicated to the client 
device. Once mapping is completed, the universal map- 
ping program transforms the mapped data into a form 
suitable for storage in the server computer system's da- 
tabase or for communication, as a vCard, to the client 
device. 

[001 1] Through the use of configuration files and pro- 
grammatic elements configured at run time in accord- 
ance with information present in a selected configura- 
tion file, the universal mapping system provides a flexi- 
ble approach to the mapping of data between two or 



more data stores having different storage structures 
and/or formats. This approach enables the universal 
mapping system to be advantageously adapted, when 
employed as part of a synchronization system for syn- 
5 chronizing personal information management, to sup- 
port new types of client devices through the mere addi- 
tion of new configuration files respectively designed for 
the new types of client devices. As a consequence, it is 
not necessary to perform the costly, time consuming and 
resource intensive design, programming, testing, and 
implementation of custom software device drivers in or- 
der for the universal mapping system to support the 
mapping of personal information management data be- 
tween a new type of client device and a synchronization 
server system. 

[0012] Importantly, the universal mapping system al- 
so provides the ability to maintain data mappings from 
previous synchronization and/or mapping sessions, 
thereby preserving the integrity of a client device's data. 
The universal mapping system, additionally, enables the 
beneficial establishment and use of priorities that gov- 
ern data mapping between data structures, and the per- 
sistence of data which significantly minimizes the poten- 
tial loss of a client device's data that might result be- 
cause certain client device data may not be mappable. 
In addition, the universal mapping system advanta- 
geously provides for the configuration and implementa- 
tion of size limits on mapped data to diminish the pos- 
sibility of a synchronization server computer system 
sending mapped data to a client device which does not 
fit, and perhaps exceeds, the limited storage capacity 
for such data at the client device. Further, the universal 
mapping system enables the configuration and imple- 
mentation of lists of characters that are not allowed for 
storage in a client device and enables the specification 
of substitute characters therefor, thereby avoiding the 
sending of mapped data including unacceptable char- 
acters to a client device. 

[001 3] Accordingly, it is an object of the present inven- 
tion to enable the mapping of data between two different 
data structures and/or formats without expenditure of 
the resources associated with the development, pro- 
gramming, testing, and implementation of software driv- 
ers. 

[0014] Another object of the present invention is to 
map data between two different data structures using a 
configuration file to specify information which controls 
the mapping process. 

[0015] Still another object of the present invention is 
to maintain the integrity of data on a client device before, 
during, and after a mapping session. 
[0016] Still another object of the present invention is 
to enable the prioritized mapping of certain data. 
[0017] Still another object of the present invention is 
to avoid the communication of mapped data to a client 
device which includes data strings having lengths that 
are too long for storage at the client device. 
[0018] Still another object of the present invention is 
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to avoid the communication of mapped data to a client 
device which includes characters which are not storable 
at the client device. 

[0019] Still another object of the present invention is 
to identify the type of client device with which mapping 5 
of data is to be performed. 

[0020] Still another object of the present invention is 
to enable the mapping of data between a common data 
structure and/or format and a proprietary data structure 
and/or format. 

[0021] Still another object of the present invention is 
to enable the mapping of personal information manage- 
ment data between the vCard data structure and/or for- 
mat and a proprietary data structure and/or format of a 
synchronization server database. 
[0022] Other objects, features, and advantages of the 
present invention will become apparent upon reading 
and understanding the present specification when taken 
in conjunction with the appended drawings. 
[0023] In the Drawings; 

[0024] Fig. 1 displays a block diagram representation 
of a system architecture for the synchronization of per- 
sonal information manager data between a synchroni- 
zation server system and a plurality of client devices in 
accordance with the preferred embodiment of the 
present invention. 

[0025] Fig. 2 displays a block diagram representation 
of the structure of the universal mapping system of Fig. 
1. 

[0026] Fig. 3 displays a textual representation of an 
exemplary PIM specification configuration file corre- 
sponding to the PIM specification configuration file iden- 
tified in Fig. 1. 

[0027] Figs. 4A and 4B display a textual representa- 
tion of an exemplary PIM specification file correspond- 
ing to one of the PIM specification files identified in Fig. 
1. 

[0028] Fig. 5 displays a textual representation of ex- 
emplary Devlnf DTD data received by the synchroniza- 
tion server system of Fig. 1 from a client device 104. 
[0029] Fig. 6 displays a flowchart representation of a 
synchronization method in accordance with the pre- 
ferred embodiment of the present invention. 
[0030] Figs. 7A, 7B, and 7C display a flowchart rep- 
resentation of an identification method in accordance 
with the preferred embodiment of the present invention. 
[0031] Fig. 8 displays a flowchart representation of a 
configuration method in accordance with the preferred 
embodiment of the present invention. 
[0032] Figs. 9A, 9B, and 9C display a flowchart rep- 
resentation of a mapping method in accordance with the 
preferred embodiment of the present invention. 
[0033] Fig. 10A displays a textual representation of 
an exemplary first vCard of an exemplary synchroniza- 
tion session in which vCard properties are mapped to 
UC fields in accordance with the preferred embodiment 
of the present invention. 

[0034] Fig. 10B displays a textual representation of 



an exemplary UC record resulting from the mapping of 
the first vCard of Fig. 1 0A during an exemplary synchro- 
nization session in which vCard properties are mapped 
to UC fields in accordance with the preferred embodi- 
ment of the present invention. 

[0035] Fig. 10C displays a textual representation of 
an exemplary second vCard of an exemplary synchro- 
nization session in which vCard properties are mapped 
to UC fields in accordance with the preferred embodi- 
ment of the present invention. 

[0036] Fig. 10D displays a textual representation of 
an exemplary UC record resulting from the mapping of 
the second vCard of Fig. 10C during an exemplary syn- 
chronization session in which vCard properties are 
mapped to UC fields in accordance with the preferred 
embodiment of the present invention. 
[0037] Fig. 11 A displays a textual representation of an 
exemplary UC record existing prior to an exemplary syn- 
chronization session in which UC fields are mapped to 
vCard properties in accordance with the preferred em- 
bodiment of the present invention. 
[0038] Fig. 1 1 B displays a textual representation of an 
exemplary vCard resulting from the mapping of the UC 
fields of Fig. 11 A during an exemplary synchronization 
session in which UC fields are mapped to vCard prop- 
erties in accordance with the preferred embodiment of 
the present invention. 

[0039] Referring now to the drawings, in which like nu- 
merals represent like elements or steps throughout the 
several views and in which an ellipsis indicates the pres- 
ence of multiple similar elements, Fig. 1 displays a block 
diagram representation of a system architecture 100 for 
the storage, retrieval, communication, and synchroniza- 
tion of personal information manager data (i.e., some- 
times also referred to herein as "PIM data", and as "con- 
tact information" or "contact data" even though such 
contact information or contact data, generally, refers to 
only one form of PIM data). The system architecture 1 00 
comprises a synchronization server system 102, a plu- 
rality of client devices 104, a telecommunication net- 
work 106, and communication links 108, 110. The syn- 
chronization server system 102 is communicable with 
each client device 104, through the telecommunication 
network 106 and appropriate communication links 108, 
110, to enable the synchronization of PIM data stored 
by the synchronization server system 102 (i.e., some- 
times referred to herein as "iPIM data", "universal con- 
tact data", or "UC data") with PIM data stored on the 
client devices 104 (i.e., sometimes referred to herein as 
"dPIM data" or "client contact information"). 
[0040] The client devices 104, preferably, comprise 
Internet-enabled wireless devices having personal in- 
formation manager applications software which are op- 
erable to communicate dPIM data to the synchroniza- 
tion server system 102 and to receive iPIM data from 
the synchronization server system 102 in the vCard for- 
mat and through use of the SyncML protocol. Exemplary 
client devices 104 include, but are not limited to, appro- 
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priately configured Internet-enabled wireless tele- 
phones, personal digital assistants, and other similar 
devices available now or in the future. The telecommu- 
nication network 106, preferably, includes the Internet 
and the appropriate facilities thereof. Communication 
link 108, preferably, comprises a wired bi-directional 
communication path having multiple channels to enable 
bi-directional communication berween the synchroniza- 
tion server system 102 and the telecommunication net- 
work 106. Communication links 110, preferably, include 
wireless bi-directional communication paths which ena- 
ble bi-directional communication between respective 
client devices 104 and the telecommunication network 
106. It should be understood that while the present in- 
vention is described in relation to system architecture 
100, the scope of the present invention is not limited to 
wireless client devices 104, to the Internet telecommu- 
nication network 104, to wired communication links 108, 
or to wireless communication links 110, but instead com- 
prises all wired or wireless client devices 104 (including, 
for example, desktop and mobile personal computers) 
capable of managing and communicating PIM data in 
any format and according to any protocol, all telecom- 
munication networks 106 and the infrastructure and fa- 
cilities thereof, and all wired or wireless communication 
paths 108, 110 and the facilities thereof. 
[0041] The synchronization server system 102, ac- 
cording to the preferred embodiment of the present in- 
vention, comprises a hardware platform (not shown) 
having one or more inter-communicable server compu- 
ter systems appropriately each configured with one or 
more processors (i.e., or central processing units) for 
executing software program instructions and manipulat- 
ing data, one or more memories (i.e., which may phys- 
ically be part of or separate from the server computer 
systems) for storing software program instructions and 
data, and a communication interface which enables the 
bi-directional communication of data with the telecom- 
munication network 106 via communication link 108 (i. 
e., and, ultimately, with respective client devices 1 04 via 
respective communication links 110). The memory, pref- 
erably, comprises many different forms, including for ex- 
ample and not limitation, random access memory, read- 
only memory, magnetic storage devices, non-magnetic 
storage devices, optical storage devices, magneto-op- 
tical storage devices, and other forms available now or 
in the future. Exemplary communication interfaces in- 
clude, without limitation, analog and digital interfaces, 
wired and wireless interfaces, analog and digital mo- 
dems, cable modems, ISDN interfaces, optical interfac- 
es, xDSL interfaces, satellite interfaces, and other com- 
munication interfaces operable to communicate data as 
required by the present invention. An appropriately con- 
figured server computer system may be available from 
Compaq Computer Corporation of Houston, Texas and 
many other server computer vendors. One reasonably 
skilled in the art should understand the selection, con- 
figuration, and operation of a server computer system 



and, therefore, it is not necessary to describe such de- 
tails herein. 

[0042] The synchronization server system 1 02 further 
comprises a software and data platform 112 having a 

5 multi-tasking, virtual operating system (not shown), a 
server iPIM storage object 114, a PIM specification con- 
figuration file 116, one or more PIM specification files 
118, and a plurality of software programs or modules 
120, 122, 124, 126 stored or present in a server com- 

io puter system memory. The multi-tasking, virtual operat- 
ing system includes a plurality of instructions which, 
when executed by a processor of the synchronization 
server system 102, control overall operation of the sys- 
tem 102 and enable various system functions such as, 

15 the storage and retrieval of instructions and data (i.e., 
including iPIM data) from memory, and the communica- 
tion of requests, commands, and data within and be- 
tween software programs and devices outside of the 
synchronization server system 102. An operating sys- 

20 tern, acceptable according to the preferred embodi- 
ment, is the "Windows 2000 Server Operating System" 
available from Microsoft Corporation of Redmond, 
Washington. The plurality of software programs or mod- 
ules 120, 122, 124, 126 implement methods described 

25 herein and, generally, include a plurality of instructions 
which, when executed by a processor of the synchroni- 
zation server system 102, cause the system 102 to per- 
form certain tasks which are required by those methods 
and which are related to the communication, mapping, 

30 and synchronization of PIM data, or to other operations 
or functions described herein. 
[0043] The server i PIM storage object 114, preferably, 
resides in a non-volatile memory device at the synchro- 
nization server system 102 and includes master iPIM 

35 data stored in a plurality of universal contact records or 
objects (i.e., sometimes referred to herein as "UC 
records" or "UC record objects") having a structure and 
format which is, generally, different than the structure 
and format employed by client devices 104 to store 

40 dPIM data and different than the structure and format 
defined by the vCard specification. Each UC record, 
generally, corresponds to a single vCard. The UC 
records have a plurality of fields or structures (i.e., 
sometimes referred to herein as "UC fields") which, pref- 

<5 erably, store: mapped contact information such as, for 
example, a contact's first name, last name, street ad- 
dress, business voice phone number, business facsim- 
ile phone number, business email address, home voice 
phone number, home facsimile phone number, home 

50 email address, and mobile phone number); historical as- 
sociation information describing the previous mapping 
of vCard properties and parameters to/from appropriate 
UC fields to provide a user of a client device 104 with 
predicted results and to avoid the loss of PIM data during 

55 multiple-point synchronization; and, unmapped contact 
information which may be present in a vCard, but which 
is not stored by the server iPIM storage object 114 in a 
UC field designated solely for a particular type of data 
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(i.e., such as for mapped contact information). Such un- 
mapped contact information may include vCard proper- 
ties that are not supported or that are supported, but that 
could not be mapped for various reasons to specific UC 
fields in a UC record. The unmapped contact informa- 
tion is saved and returned to the client device 1 04 during 
a client update operation. Generally, the UC record ob- 
jects and their data are actually stored, retrieved, and 
updated by a synchronization engine program 122 de- 
scribed below. 

[0044] The historical association information is, pref- 
erably, stored with each UC record as a history/associ- 
ation table using a name value scheme and a fixed 
name to enable storage and retrieval of the table. The 
history/association table, preferably, comprises a vCard 
slot/line number, a vCard property type, a universal sub- 
type/field identifier, vCard property parameter charac- 
teristics, a value on the client device 104, and an extra 
storage name. The vCard slot/line number is utilized in 
an attempt to preserve the order in which properties are 
received from a vCard (i.e., which may be important to 
prioritize PIM data during mapping) since vCard prop- 
erties may span several lines and do not contain unique 
identifiers. The vCard property type is used by vCard 
property mappers 206 (described below) to search the 
history/association table for vCard properties that the 
mappers 206 are responsible for mapping. The univer- 
sal sub-type/field identifier stores a value of the UC field 
to which the data has been synchronized or a value in- 
dicating that the vCard property was not synchronized 
to the UC field, but was stored for subsequent retrieval 
and return to the client device 1 04 during a client update. 
The vCard property characteristics include a bitmap in- 
dicating which of the defined vCard property parameters 
were present in the received vCard. The bitmap is used 
to reconstruct the vCard property to the same value that 
was received. The value on the client device 104 repre- 
sents the value of a vCard property in the format utilized 
by the client device 104 and is necessary because the 
format used to store a vCard property in the server iPIM 
storage object 114 may not be the same as the format 
preferred by the user of the client device 104. Storage 
of the value on the client device 104 is also required 
since vCard properties do not have unique identifiers 
and, during an update, reliance is necessary on a com- 
parison of data received from a vCard and the stored 
value in the history/association table. The extra storage 
name represents the name of a UC field in which vCard 
property data is stored if the data is not supported by 
the synchronization server system 102, cannot be 
mapped to a UC field, or contains extended parameters 
which cannot be represented internally in the server iP- 
IM storage object 114. The extra storage name is utilized 
during an update of a client device 104 to retrieve such 
data and construct a vCard for return to the client device 
104. 

[0045] As described above, the historical association 
information describes previous mappings of vCard 



properties and parameters to/from appropriate UC fields 
to provide a user of a client device 104 with predicted 
results from the synchronization of PIM data between 
the server system 102 and the user's client device 104. 

5 For example, suppose that during a previous synchro- 
nization session, the vCard property "B" is selected for 
mapping to the server UC field "X" from a group of vCard 
properties including "A", "B", and "C" in accordance with 
priority rules described below. By storing the association 

10 between (i.e., and mapping of) vCard property "B" and 
UC field "X" in the history/association table, the associ- 
ation may be retrieved during subsequent synchroniza- 
tion sessions and utilized to cause the mapping of vCard 
property "B" into UC field "X" during those sessions, 

15 thereby preserving the integrity of the PIM data of the 
client device 104. 

[0046] The PIM specification configuration file 116, 
preferably, resides in a non-volatile memory device of 
the synchronization server system 102 and includes in- 
20 formation utilized by the synchronization engine pro- 
gram 122, as described below, to (i) identify the device 
type of a client device 1 04 which desires to synchronize 
its contact information with the contact information 
stored in the synchronization server system's iPIM stor- 
es age object 114, and (ii) select the appropriate PIM spec- 
ification file 118 corresponding to the identified device 
type. The PIM specification configuration file 116 is, 
preferably, formatted in Extensible Markup Language 
("XML") and, as depicted in Fig. 3, includes information 
30 describing different types of client devices 1 04. The in- 
formation is arranged in the form of one or more device 
entries 302 with each entry 302 being uniquely associ- 
ated in one-to-one correspondence with only one type 
of client device 104. Note that while the entries 302 dis- 
ss played in Fig. 3 are, preferably, associated with types of 
client devices 104 which are wireless handheld client 
devices 104 (i.e., mobile telephones), the PIM specifi- 
cation configuration file 116 may include, within the 
scope of the present invention, entries 302 which are 
40 associated with other types of client devices 104 such 
as, for example and not limitation, Internet-enabled per- 
sonal digital assistants, desktop computers, and porta- 
ble computers. 

[0047] Each entry 302 of the PIM specification config- 
45 uration file 116, preferably, comprises a name element 
or tag ("<Nam>") 304 which specifies the name of the 
PIM specification file 118 to be utilized by a universal 
mapping program 126 to configure itself, as described 
below, for the mapping of contact information commu- 
50 nicated between an associated type of client device 1 04 
and the synchronization server system 102 according 
to the SyncML protocol and the vCard specification. As 
a consequence, once an entry 302 is identified by the 
synchronization engine program 122 as corresponding 
55 to the device type of the client device 104, the name of 
the PIM specification file 118 is also identified, thereby 
enabling selection of the appropriate PIM specification 
file 118 from the plurality of available PIM specification 
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files 118. Each entry 302 also, generally, comprises: a 
manufacturer element or tag ("<Man>") 306 which iden- 
tifies the name of the manufacturer of the associated 
type of client device 104. and a model number element 
or tag f<Mod>") 308 which identifies the model number 
assigned to the associated type of client device 104 by 
the device's manufacturer. Each entry 302 may addition- 
ally contain other elements or tags, including for exam- 
ple and not limitation: hardware, software and version 
elements or tags f<Hwv>\ "<Swv>", and "<Fwv>") 31 0, 
312, 314 which respectively identify the version of the 
hardware, software, and firmware present in and being 
utilized by the associated type of client device 104; an 
original equipment manufacturer element or tag 
("<Oem>") 316 which identifies the name of the original 
equipment manufacturer of the associated type of client 
device 104 (i.e., since the associated type of client de- 
vice 1 04 may have been produced by one manufacturer, 
but marketed under a different manufacturer's name); a 
user agent element or tag ("<Usr>") 31 8 which identifies 
the user agent utilized by the associated type of client 
device 104; and, a default element or tag ("<Def>") 320 
which identifies whether the associated entry 302 qual- 
ifies as a default entry 302 for use by the universal map- 
ping program 126 in the event that an entry 302 cannot, 
otherwise, be identified for a particular client device 104. 
[0048] The plurality of PIM specification files 118 of 
Fig. 1 , preferably, reside in a non-volatile memory de- 
vice of the synchronization server system 1 02 with each 
PIM specification file 118 being uniquely associated in 
one-to-one correspondence with a particular type of cli- 
ent device 104 and with an entry 302 in the PIM speci- 
fication configuration file 116. Since each type of client 
device 104 may interchange parameters of a vCard with 
contact information stored in its dPIM storage object 1 30 
differently than another type of client device 104 (i.e., 
different client devices 104 may implement the inter- 
change of dPIM data with vCards differently), different 
PIM specification files 118 are necessary for each re- 
spective type of client device 104, but not for different 
client devices 104 of the same device type. Each PIM 
specification file 118 is, preferably, formatted in Exten- 
sible Markup Language ("XML") and, as illustrated in 
Figs. 4A and 4B, includes configuration elements 402 
which are utilized by the universal mapping program 126 
to configure itself for mapping PIM data, in either direc- 
tion, between the UC records of the server iPIM storage 
object 114 and the properties of vCards interchanged 
with the file's associated type of client device 104. The 
configuration elements 402 of each PIM specification 
file 118 include, for example and not limitation, informa- 
tion identifying the vCard properties which are mapped 
for the associated type of client device 104, definitions 
of mappings between UC fields and vCard properties, 
priority rules to apply during mapping, individual map- 
ping component attributes, size limits and allowed al- 
phabetic characters for particular fields of the client de- 
vice's dPIM storage object 1 30, and character mappings 



for alphabetic characters that are not allowed in partic- 
ular fields of the client device's dPIM storage object 1 30. 
[0049] Before proceeding with a more detailed de- 
scription of the configuration elements 402 allowable in 

5 a PIM specification file 118. it should be remembered 
that vCards are organized into properties, including, 
TEL, ADR, EMAIL, and various other properties. Each 
property is broken down into property parameters such 
as WORK, VOICE, and property specific values. Due at 

10 least in pan to a vCard's use of such properties and pa- 
rameters, the mapping definitions between UC fields 
and vCards, generally, include configuration elements 
402 that reference the vCard properties and parame- 
ters. Exemplary vCard property parameters that are 

15 supported by the universal mapping program 126 in- 
clude: POSTAL, PARCEL, PREF, CELL, MSG, HOME, 
WORK, FAX, VOICE, INTERNET, AOL, APPLELINK, 
ATTMAIL, CIS, EWORLD, MODEM, CAR, ISDN, VID- 
EO, PCS, IBMMAIL, MCIMAIL, POWERSHARE, 

20 PRODIGY, TLX, QP, DOM, INTL, BBS, PAGER, X400, 
and NULL. 

[0050] The exemplary PIM specification file 118 of 
Figs. 4A and 4B comprises a header element 404 
("<PimSpec>") and a top level vCard-based element 

25 406 f-cVCardTypes^) which allow, respectively, for fu- 
ture expansion and inclusion of other configuration ele- 
ments 402 that may not be PIM related and non-vCard- 
based elements (i.e., configuration elements 402 which 
may enable configuration of the universal mapping pro- 

30 gram 126 to map information pertaining to calendars/ 
appointments ("ICal" elements), to do lists, and various 
other PIM-type applications. The PIM specification file 
118 also comprises attributes 408 for the general pur- 
pose mapping components that are mapped from/to the 

35 file's associated type of client device 1 04. If an attribute 
408 related to a particular UC field or vCard property is 
not present in the PIM specification file 118, the partic- 
ular UC field or vCard property will not be mapped by 
the universal mapping program 126. Such attributes in- 

40 elude, but are not limited to: a telephone number at- 
tribute 408A ("<TEL>"); an address attribute 408B 
("<ADR>"); an electronic mail address attribute 408C 
(""<EMAIL">); a full name attribute 408D ("<FN>"); a 
name attribute 408E (^N^); and, a universal resource 

45 locator attribute 408F f<URL>"). Other supported, but 
not shown attributes 408 include, for example and not 
limitation: a note attribute ("<NOTE>"); a birthday at- 
tribute ("<BDAY>"); a nickname attribute (^NICK- 
NAMED); an organization attribute ("ORG^); and, a 

50 title attribute ("<TITLE>"). 

[0051] The top level vCard-based element 406, as 
seen in Figs. 4A and 4B, supports a maximum number 
of contacts configuration element 402A ("<MaxCon- 
tacts>") and a maximum vCard size configuration ele- 

55 ment 402B which, respectively, identify the maximum 
number of contacts and the maximum size, in bytes, of 
a vCard supported by the associated type of client de- 
vice 104. Similarly, each of the attributes 408 supports 
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particular configuration elements 402 which are related 
to the attribute and which provide information necessary 
during mapping operations. Some attributes 408 sup- 
port configuration elements 402 which include, but are 
not limited to, information which identifies the type of 5 
mapping and priority rules to be employed by the uni- 
versal mapping program 126. Priority rules are neces- 
sary to guide the universal mapping program 126 in the 
selection of UC fields during mapping and must be 
present when a type of client device 104 has a PIM spec- 
ification file 118 that is limited in respect to the server 
PIM. Priority rules may be hard-coded within the source 
code of the universal mapping program 126, but may 
also comprise custom priority tables associated with an 
attribute 408. Such priority rules and tables may be de- 
fined for "inbound" mapping (i.e., mapping vCard prop- 
erties and their combination of property parameters to 
a single UC field) and for "outbound" mapping (i.e., map- 
ping from a UC field to a vCard property). The need for 
priority rules may be explained by considering the ex- 
emplary situation that arises when vCard properties "A", 
"B", and "C" may be mapped into UC field "X", but there 
is no logical reason to concatenate the properties. 
Through the use of priority rules, one of the vCard prop- 
erties maybe chosen for mapping to the UC field "X". 
[0052] In further example, the telephone number at- 
tribute 408A ("<TEL>") supports a priority rules config- 
uration element 402C ("<PriorityRules>") which identi- 
fies whether standard priority rules are to be applied by 
the universal mapping program 126 when performing 
mapping operations. The telephone number attribute 
408A and certain other attributes 408 may also include, 
as seen in Figs. 4A and 4B, custom priority rules which 
are specified in the form of a priority sub-type table 402D 
or priority type tables 402E. A priority sub-type table 
402D is defined by a universal contact sub-type config- 
uration element 402F ("<UCSubType>") and identifies 
the sub-type, or one-to-one, custom mapping used 
when a vCard property and its combination of property 
parameters is to be uniquely mapped to a single UC field 
or when mapping from a UC field to a vCard. Such one- 
to-one mapping has priority over other forms of support- 
ed mapping, including type mapping described below. 
As seen in Fig. 4A, the universal contact sub-type con- 
figuration element 402F references an exemplary "Busi- 
nessFax" configuration element 402G for a UC record 
to specify a mapping of the vCard WORK and FAX prop- 
erty parameters 41 OA, 41 0B to the BusinessFax field of 
a UC record. Other exemplary configuration elements 
402 for fields of a UC record include, but are not limited 
to: Assistant, Business, Business2, Callback, Car, Com- 
pany, Home, Home2, HomeFax, Isdn, Mobile, Other, 
OtherFax, Pager, Primary, Radio, and Telex. 
[0053] A priority type table 402E is defined by a uni- 
versal contact type configuration element 402 H ("<UC- 
Type>") and identifies the type mapping used when a 
combination of vCard property parameters are mapped 
to a group (i.e., type) of UC fields of a UC record. The 



UC fields of each group are, typically, arranged accord- 
ing the order in which the UC fields are to be selected 
for mapping of vCard property parameters by the uni- 
versal mapping program 126 with the highest priority 
fields being at the top of the definition. The types and 
fields for each type are defined as configuration ele- 
ments 402 which are recognized by a PIM specification 
file parser 202 described below. Exemplary UC Types 
and their respective UC fields (i.e., in parenthesis) which 
are recognized by the parser 202 include: Primary (Pri- 
mary); Business (Business, Business2, Assistant, Com- 
pany); Home (Home, Home2, Callback); Mobile (Mo- 
bile, Car); Fax (BusinessFax, HomeFax, OtherFax); 
Pager (Pager); Other (Other); ISDN (Isdn); Radio (Ra- 
dio); Telex (Telex); and, TTY (Tty). 
[0054] According to the preferred embodiment and as 
displayed in Fig. 1, the software and data platform 112 
of the synchronization server system 102 includes a 
web server program 120 (i.e., sometimes also referred 
to herein as "web server 120") having computer soft- 
ware instructions which, when executed by a processor 
of the system 102, enables bi-directional communica- 
tion of vCards with the plurality of client devices 104 
through telecommunication network 106 and communi- 
cation links 108, 110. The web server 120 also, prefer- 
ably, provides an Internet web site interface for interac- 
tion with the client devices 1 04 via the web site interface. 
The software and data platform 1 1 2 of the synchroniza- 
tion server system 102 also includes a synchronization 
engine program 122 (i.e., sometimes also referred to 
herein as "sync engine 122") which, when executed by 
a processor of the system 102, is operable to store and 
retrieve UC records in and from the server iPIM storage 
object 114. The sync engine 122 is also operable to 
identify, select, and communicate (i.e., to the universal 
mapping program 126) the name of a PIM specification 
file 118, in accordance with methods described below, 
which is appropriate for a client device 104 desiring to 
synchronize its dPIM data with the master iPIM data of 
the synchronization server system 102. 
[0055] The software and data platform 1 1 2 of the syn- 
chronization server system 102 additionally comprises 
a SyncML server program 124 (i.e., sometimes also re- 
ferred to herein as "SyncML server 124") having com- 
puter software instructions which, when executed by a 
processor of the system 102, is operable to call the uni- 
versal mapping program methods MapToUC () and 
MapTovCard () upon receipt of a vCard or a request for 
an update of the dPIM data of a client device 104 re- 
ceived from the web server 120 and the sync engine 
122, and to thereby initiate mapping of PIM data be- 
tween the server iPIM storage object 114 and a vCard. 
The SyncML server 124 is also operable to handle pro- 
tocol conversion and/or related tasks associated with 
the communication of vCards via the SyncML protocol. 
The software and data platform 112 further comprises a 
universal mapping program 126, described in more de- 
tail below, which enables the bi-directional mapping of 
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PIM data between a vCard and the master iPIM storage 
object 114. Together, the universal mapping program 
126 and the plurality of PIM specification files 118 form 
the universal mapping system 140. 
[0056] In accordance with the preferred embodiment 5 
of the present invention, each client device 104, prefer- 
ably, comprises a hardware platform (not shown) having 
a processor for executing software program instructions 
and manipulating data, one or more memories for stor- 
ing software program instructions and data, one or more 
user interfaces (i.e., keypad, display, microphone, 
speaker), and a communication interface which enables 
the bi-directional communication of data (i.e., in the form 
of vCards) with the telecommunication network 106 via 
a communication link 110 (i.e., and, ultimately, with the 
synchronization server system 102 via communication 
link 108). Each client device 104 also, preferably, com- 
prises a software and data platform 128 including a cli- 
ent dPIM storage object 130 for storing dPIM data as- 
sociated with contacts of the device's user, and a plu- 
rality of software programs having software instructions 
which cause the client device 104 to perform certain 
tasks and provide certain functionality when executed 
by the device's processor. The plurality of software pro- 
grams comprises a personal information manager pro- 
gram 132 (i.e., sometimes also referred to herein as 
"PIM manager 132") for enabling the device's user to 
locally input, delete, edit, and view dPIM data, to initiate 
PIM data synchronization with the synchronization serv- 
er system 102, and to store and retrieve dPIM data in 
and from the client dPIM storage object 1 30. The plural- 
ity of software programs also comprises a SyncML client 
software program 134 (i.e., sometimes also referred to 
herein as "SyncML client 134") and a vCard mapping 
software program 136 (i.e., sometimes also referred to 
herein as "vCard mapper 136") which, preferably, work 
in conjunction with the PIM manager 1 32 to synchronize 
PIM data in the client dPIM storage object 130 and the 
server iPIM storage object 114. The SyncML client 134 
and vCard mapper 1 36 are, respectively, operable to en- 
able the bi-directional communication of vCards with the 
telecommunication network 106 (i.e., and, ultimately, 
with the synchronization server system 1 02) via the Syn- 
cML protocol, and to bi-directionally map PIM data be- 
tween a vCard and the client dPIM storage object 130. 
[0057] Fig. 2 displays a block diagram representation 
of the universal mapping system 140 according to the 
preferred embodiment of the present invention. The uni- 
versal mapper 126, described briefly above, is a com- 
ponent of the synchronization server system 102 that is 
responsible for the bi-directional mapping of contact in- 
formation stored in a dPIM storage object 130 of a client 
device 104 and contact information stored in the iPIM 
storage object 114 of the synchronization server system 
1 02, with the contact information of both storage objects 
114, 130 being exchanged, preferably, in the form of 
vCards communicated therebetween via the SyncML 
protocol. The universal mapper 126 is designed as a 



framework from which standard vCard mapping objects 
are configurable to perform mappings specific to a type 
of client device 104 and to which custom mapping ob- 
jects may be added at various times. The client specific 
mappings are defined by a PIM specification file 118, 
described above, that is identified and communicated (i. 
e., by name) to the universal mapper 126 by the sync 
engine 122. The PIM specification file 118 provides the 
universal mapper 126 with configuration elements 
which describe properties for the mapping objects, in 
addition to unique mappings of vCard properties and pa- 
rameters to fields of the UC records of the server iPIM 
storage object 114. 

[0058] In accordance with the preferred embodiment 
of the present invention, the universal mapper 1 26 com- 
prises a PIM specification file parser 202, a plurality of 
configuration element handlers 204, a plurality of vCard 
mapping objects 206 (i.e., sometimes also referred to 
herein as "vCard property mappers 206"), and a PIM 
specification object 208. The PIM specification file pars- 
er 202 is, preferably, an event-based parser which is op- 
erable to parse the configuration elements 402 of a PIM 
specification file 1 18 upon receipt of the name of the PIM 
specification file 118 from the sync engine 122. The PIM 
specification file parser 202 is operable to identify or de- 
tect a previously sub-classed event (i.e., such as, for 
example and not limitation, the start of an element, the 
end of an element, or the presence of character data) 
in the PIM specification file 118 and to, upon such de- 
tection, call a configuration element handler 204 for that 
event. During operation, the PIM specification file parser 
202 configures itself by building a stack of configuration 
element handlers 204 that are responsible for process- 
ing each particular configuration element 402 of the PIM 
specification file 1 1 8 or for constructing one or more sub- 
handlers for the configuration element 402. Each con- 
figuration element handler 204 is, generally, designed 
to process a single configuration element 402, to con- 
struct appropriate sub-handlers as necessary to proc- 
ess the configuration element 402, and to destruct the 
sub-handlers when processing of the configuration ele- 
ment 402 is complete. The configuration element han- 
dlers 204 are also, generally, designed to retrieve and 
store configuration element values that are used to con- 
struct vCard property mappers 206, and to add unique 
identifiers associated with the mappers 206 to a list of 
vCard property mappers 206 of the PIM specification 
object 208. The list of vCard property mappers 206 de- 
fines the sequence in which the mappers 206 are called 
during mapping operations described below. The PIM 
specification object 208, generally, holds the specific 
mapping properties and objects for a particular type of 
client device 104, and also includes a map which is uti- 
lized to retrieve the mappers 206 based on the identifi- 
ers present in the list of vCard property mappers 206. 
[0059] Each vCard property mapper 206 is, prefera- 
bly, operable to map or transform a vCard property to or 
from a UC field of a UC record of the iPIM storage object 
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114 and includes methods for performing such transfor- 
mation in either direction (i.e., MapToUC () and Map- 
To VC ()). Each vCard property mapper 206 receives ap- 
propriate configuration element data (i.e., including, for 
example and not limitation, size limits, allowable and/or 5 
mapped characters, maximum allowable number of 
fields of the same type, and priorities between types) 
from the parsing of the PIM specification file 118 and 
utilizes the data to perform appropriate mapping. Once 
an association has been established between a UC field 
of a UC record and a vCard property (and, hence, be- 
tween iPIM and dPIM data fields), each vCard property 
mapper 206 causes storing of the association in the iPIM 
storage object 114 in the history/association table asso- 
ciated with each respective UC record and attempts to 
preserve that association in future mappings until an up- 
date is made that breaks the association. The vCard 
property mappers 206 are operable to give such an as- 
sociation priority over the mapping of new vCard prop- 
erties and UC record fields. The vCard property map- 
pers 206 are farther operative to cause the storing of 
unmapped vCard properties and parameters in the UC 
field of a UC record (i.e., identified by the extra storage 
name of the history/association table) to enable their re- 
turn to a client device 104 upon updating of contact in- 
formation on the client device 104. 
[0060] In operation, the synchronization server sys- 
tem 102 and its various component programs function 
in accordance with methods of the preferred embodi- 
ment of the present invention described herein. As illus- 
trated in the flowchart representation of a synchroniza- 
tion method 600 displayed in Fig. 6, the synchronization 
server system 102 initiates a synchronization session, 
at step 602, when the server 102 receives a vCard from 
a client device 104 that has constructed the vCard from 
its dPIM data (i.e., through appropriate operation of the 
client device's PIM manager 132 and vCard mapper 
1 36) and has submitted the vCard to the synchroniza- 
tion server system 102 through operation of the client 
device's SyncML client 134 and communication of the 
vCard to the server 102 via telecommunication network 
106 and communication paths 108, 110. Upon receipt 
of the vCard via the server's web server 120, the vCard 
is communicated internally to the server's sync engine 
122, SyncML server 124, and universal mapper 126. In- 
itiation of a synchronization session may also occur as 
a result of a request for updating of a client device 104 
being made. Regardless of the event causing initiation 
of the synchronization session and the direction of the 
synchronization, operation of the synchronization serv- 
er system 102 is substantially the same. 
[0061] Next, at step 604, the sync engine 122 at- 
tempts to identify a PIM specification file 118 which cor- 
responds to the device type of the client device 104 that 
submitted the vCard to the synchronization server sys- 
tem 102. As described in more detail below with respect 
to the preferable identification method 700, the sync en- 
gine 122 receives device identification data from the 



submitting client device 104 in the form of Devlnf DTD 
data 500 displayed in Fig. 5. Such receipt may be in re- 
sponse to a request for the identification data forwarded 
to the client device 104 from the sync engine 122. Note 
that the Devlnf DTD data 500, preferably, includes ele- 
ments or tags 502 corresponding to many of the ele- 
ments or tags of entries 302 of the PIM specification con- 
figuration file 116. For instance, the Devlnf DTD data 
500 includes both manufacturer and model elements 
502A, 502B which correspond to the manufacturer and 
model elements 306, 308 of the PIM specification con- 
figuration file 116. Similarly, the Devlnf DTD data 500 
includes hardware and software version elements 
502C, 502D which correspond to the hardware and soft- 
ware version elements 31 0, 31 2 of the PIM specification 
configuration file 116. The sync engine 122 utilizes the 
correspondence between elements in accordance with 
identification method 700 to identify the name of a PIM 
specification file 118 appropriate for the device type of 
the client device 104. 

[0062] Once the sync engine 122 has identified the 
name of the PIM specification file 118 corresponding to 
the client device type, the SyncML server 124 initiates 
mapping operations by calling the appropriate universal 
mapper method, MapToUC (i.e., to map vCard proper- 
ties to fields of a UC record) or MapToVCard (i.e. , to map 
fields of a UC record to vCard properties), and by pass- 
ing the name of the previously identified PIM specifica- 
tion file 118 to the universal mapper 126. In response, 
the universal mapper 126, at step 606, configures itself 
for mapping operations, in the direction appropriate for 
the method called by the SyncML server 124, according 
to a configuration method 800 displayed in Fig. 8 and 
described below. Then, at step 608, the synchronization 
method 600 branches to cause operation of the syn- 
chronization server system 102 according to the direc- 
tion of mapping. If PIM data is to be mapped from a 
vCard to a UC record (i.e., the MapToUC method was 
called by the SyncML server 124), the universal map- 
ping program 126, at step 610, maps vCard properties 
and parameters to a UC record object having iPIM types 
and sub-types and passes the UC record object. A de- 
tailed description of the employed mapping method 900 
is described below with reference to Fig. 9. Then, at step 
61 2, the sync engine 1 22 updates the server's iPIM stor- 
age object 114 with the data from the UC record object 
and, at step 614, terminates synchronization opera- 
tions. If, at step 608, PIM data is to be mapped from a 
UC record to a vCard (i.e. , the MapToVCard method was 
called by the SyncML server 1 24), the universal mapper 
126, at step 61 6, maps fields of a UC record having iPIM 
types and sub-types into vCard properties and param- 
eters (see Fig. 9) and passes the vCard to the SyncML 
server 1 24 for communication of the vCard, at step 618, 
to the client device 104 using the SyncML protocol. The 
synchronization method 600 then terminates at step 
620. 

[0063] As described briefly above, the sync engine 
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122 operates according to a preferred identification 
method 700 in an attempt to identify a PIM specification 
file 118 which corresponds to the device type of the cli- 
ent device 1 04 that submitted the vCard to the synchro- 
nization server system 1 02. Figs. 7A, 7B, and 7C display 5 
a flowchart representation of the preferred identification 
method 700. After starting at step 702, the method 700 
proceeds to step 704 where the sync engine 122 re- 
ceives device identification data from the submitting cli- 
ent device 1 04 in the form of Devlnf DTD data 500 sim- 
ilar to that displayed in Fig. 5. Then, at step 706, the 
sync engine 122 uses the manufacturer and model ele- 
ments 502A, 502B of the Devlnf DTD data 500 and the 
PIM specification configuration file 116 to create a list, 
or set, of entries 302 from the PIM specification config- 
uration file 116 having values for manufacturer and mod- 
el number elements 306, 308 that match the values for 
the manufacturer and model number elements 502A, 
502B. The sync engine 122, at step 708, determines 
whether the list, or set, of entries 302 is empty. If so, the 
sync engine 1 22 branches to step 746 described below. 
If not, the sync engine 122 proceeds to step 710 where 
it determines whether each entry 302 of the set has been 
tested for matches of the entry's firmware version, orig- 
inal equipment manufacturer name, software version, 
and hardware version elements 314, 316, 312, 310 with 
similar elements of the Devlnf DTD data 500. 
[0064] If, at step 71 0, the sync engine 1 22 determines 
that all entries of the set of entries 302 have been tested, 
the sync engine 1 22 branches to step 730 described be- 
low. Alternatively, if the sync engine 122 determines that 
ail of the set of entries 302 have not been tested, the 
sync engine 122 advances to step 712 where it begins 
testing associated with the next entry 302 of the created 
set of entries 302 by determining whether the received 
Devlnf DTD data 500 includes a firmware version ele- 
ment. If not, the sync engine 122 branches to step 716 
described below. If so, the sync engine 122 branches to 
step 714 where it decides whether the value of firmware 
version element of the Devlnf DTD data 500 matches 
the value of the firmware version element 314 of the en- 
try 302. If no match is found, the sync engine 1 22 returns 
to step 710 described above. If a match is found, the 
sync engine 122 continues at step 716 where it ascer- 
tains whether an original equipment manufacturer ele- 
ment is present in the Devlnf DTD data 500. If no original 
equipment manufacturer element is present, the sync 
engine 122 advances to step 720 described below. If an 
original equipment manufacturer element is present in 
the Devlnf DTD data 500, the sync engine 1 22 branches 
to step 718 where it decides whether the value of the 
original equipment manufacturer element in the Devlnf 
DTD data 500 matches the value of the original equip- 
ment manufacturer element 31 6 for the entry 302 of the 
created set of entries 302 which is being tested, If no 
match is found, the sync engine 122 returns to step 710 
described above. If a match is found, the sync engine 
122 continues testing of the entry 302 at step 720. 



[0065] The sync engine 122, at step 720, ascertains 
whether the received Devlnf DTD data 500 includes a 
software version element. If not, the sync engine 122 
branches to step 724 described below. If so, the sync 
engine 122 branches to step 722 where it decides 
whether the value of software version element of the 
Devlnf DTD data 500 matches the value of the software 
version element 3 1 2 of the entry 302 of the set of entries 
302 being tested. If no match is found, the sync engine 
122 returns to step 710 described above. If a match is 
found, the sync engine 122 continues at step 7724 
where it determines whether a hardware version ele- 
ment is present in the Devlnf DTD data 500. If no hard- 
ware version element is present, the sync engine 122 
returns to step 710 described above. If a hardware ver- 
sion element is present in the Devlnf DTD data 500, the 
sync engine 1 22 decides, at step 726, whether the value 
of the hardware version element in the Devlnf DTD data 
500 matches the value of the hardware version element 
310 of the entry 302 being tested. If no match is found, 
the sync engine 122 loops back to step 710 described 
above. If a match is found, the entry 302 being tested 
corresponds to the type of client device 104 identified 
by the Devlnf DTD data 500. Then, at step 728, sync 
engine 122 returns the name of the PIM specification 
file 118 found in the name element 304 of the entry 302 
being tested and ceases operation according to the 
identification method 700. 

[0066] At step 730, the sync engine 1 22 begins oper- 
ation in accordance with a portion of the identification 
method 700 which checks each entry 302 of the list, or 
set, of entries 302 created at step 706 to identify the first 
entry 302 which qualifies as a default entry (i.e., an entry 
302 having a default element 320 with a value of -true"). 
The sync engine 122 determines, at step 730, whether 
all entries 302 of the created list of entries 302 have 
been tested. If so, the sync engine 122 advances to step 
738 described below. If not, the sync engine 1 22, at step 
732, tests the next entry 302 and decides whether the 
entry 302 has a default element 320. If the entry 302 has 
no default element 320, the sync engine 1 22 returns to 
step 730 described above. If the entry 302 has a default 
element 320, the sync engine 122 examines the value 
of the default element 320 and determines whether the 
value is "true". If not, the sync engine 122 loops back to 
step 730 described above. If so, the sync engine 122 
returns the name of the PIM specification file 118 found 
in the name element 304 of the entry 302 being tested 
and stops operation in accordance with the identification 
method 700. 

[0067] At step 738, the sync engine 122 initiates op- 
eration according to a portion of the identification meth- 
od 700 which ascertains whether any of the entries 302 
of the created list of entries 302 has a user agent ele- 
ment 318. The sync engine 122 decides, at step 738, 
whether all of the entries 302 of the created list of entries 
302 have been tested. If not, the sync engine 122 de- 
termines, at step 740, whether the entry 302 being test- 
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ed has a user agent element 318. if no user agent ele- 
ment 318 is found, the sync engine 122 returns to step 
738 described above. If a user agent element 318 is 
found, the sync engine 122 decides whether the value 
of the user agent element 318 matches the value of the 5 
user agent element of the received Devlnf DTD data 
500. If there is no match, the sync engine 122 loops back 
to step 738 described above. If a match is found, the 
sync engine 122 returns the name of the PIM specifica- 
tion file 1 1 8 present in the name element 304 of the entry 
302 being tested and terminates operation according to 
the identification method 700. 

10068] If the sync engine 1 22 decides at step 738 that 
all entries 302 of the created list of entries 302 have 
been tested, the sync engine 122, at step 746, deter- 
mines whether a default PIM specification file name var- 
iable has a value. If so, the sync engine 122 stops op- 
eration in accordance with the identification method 700 
at step 748 and returns the name stored in the default 
PIM specification file name variable as the name of the 
PIM specification file 118 to be employed during config- 
uration of the universal mapper 1 26 as described below. 
If not, at step 750, the sync engine 122 stops operation 
according to the identification method 700 and returns 
a hard-coded PIM specification file name as the name 
of the PIM specification file 118 to be used dunng con- 
figuration of the universal mapper 126. 
[0069] Fig. 8 displays a configuration method 800 uti- 
lized and implemented by the universal mapper 1 26, de- 
scribed briefly above, to configure itself and the PIM 
specification object 208 in accordance with the pre- 
ferred embodiment of the present invention. After start- 
ing operation according to the configuration method 800 
at step 802, the universal mapper 126 receives the 
name of the PIM specification file 118 from the sync en- 
gine 122 which the sync engine 122 has determined to 
appropriate for use with the type of client device 104 
with which synchronization of PIM data is to occur. Then, 
at step 806, the PIM specification file parser 202 of the 
universal mapper 126 processes the PIM specification 
file 118 identified by the sync engine 122. The parser 
202 identifies and parses configuration elements 402 
present in the PIM specification file 118 and detects pre- 
viously sub-classed events (i.e., such as, for example 
and not limitation, the start of an element, the end of an 
element, or the presence of character data) in the PIM 
specification file 118. Upon detecting a configuration el- 
ement 402 and/or a sub-classed event, the parser 202 
configures the universal mapper 126 by constructing a 
stack of configuration element handlers 204 that are re- 
sponsible for processing the configuration element 402. 
Each configuration element handler 204 of the stack 
processes the configuration elements 402 that it is re- 
sponsible for (i.e., and no other configuration elements 
402), constructs appropriate sub-handlers that it needs 
to process the configuration elements 402, and de- 
structs the sub-handlers when processing of the config- 
uration elements 402 are complete. 



[0070] Continuing at step 808 of the configuration 
process 800, the configuration element handlers 204 re- 
trieve and store configuration element values from the 
PIM specification file 118 which are associated the con- 
figuration elements being processed, or handled, by the 
handlers 204. Then, the configuration element handlers 
204 construct vCard property mappers 206 to map re- 
spective vCard properties to or from a respective UC 
field(s) of a UC record of the iPIM storage object 114. 
Such construction includes the creation of vCard prop- 
erty mappers 206 having methods for performing the 
mapping of PIM data in either direction (i.e., MapToUC 
() and MapToVC ()), and the provision of the retrieved 
configuration element values (i.e., including, for exam- 
ple and not limitation, data related to size limits, allow- 
able and/or mapped characters, maximum allowable 
number of fields of the same type, and mapping priority 
rules) to the vCard property mappers 206. Next, the uni- 
versal mapper 126 adds unique identifiers associated 
with the mappers 206 to a list of vCard property mappers 
206 of the PIM specification object 208 in the sequence 
in which the mappers 206 are called during mapping op- 
erations described below. The universal mapper 126 al- 
so adds mapping information to the PIM specification 
object 208 to enable retrieval of the mappers 206 based 
on the identifiers present in the list of vCard property 
mappers 206. After adding the mapping information to 
the PIM specification object 208, the universal mapper 
126 ceases operation in accordance with the configura- 
tion method 800 at step 810. 

[0071] Figs. 9A, 9B, and 9C depict a mapping method 
900 of the preferred embodiment which is utilized and 
implemented by the universal mapper 126 to map PIM 
data in the direction (i.e., to/from vCard) associated with 
the universal mapper method, MapToUC or MapToV- 
Card, called by the SyncML server 1 24 as described 
above. Broadly, the mapping method 900 comprises 
steps of calling each configured vCard property mapper 
206 and allowing each vCard property mapper 206 to 
process the vCard property for which it is responsible. 
Then, for unmapped properties, the respective PIM data 
is stored as unmappable data and added to the history/ 
association table. More specifically, after starting oper- 
ation according to the mapping method 900 at step 902, 
the universal mapper 126 examines the list of vCard 
property mappers of the PIM specification object 208 
and determines whether all of the configured vCard 
property mappers 206 have been called. If so, the uni- 
versal mapper 126 branches to step 918 described be- 
low. If not, the universal mapper 126 utilizes the list and 
mapping information of the PIM specification object 208 
to call, or retrieve, the next vCard property mapper 206 
in the sequence identified by the list and the appropriate 
MapToXX method of the mapper 206 according to the 
direction of the synchronization session. 
[0072] Continuing at step 906, the called vCard prop- 
erty mapper 206 searches the history/association table 
for a match on the property name, parameters, and ac- 
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tual data in an attempt to identify the mapping(s) that 
were made, if any, during the previous synchronization 
session(s) for the field(s) and/or vCard property for 
which the called vCard property mapper 206 has map- 
ping responsibility. If a previous mapping(s) is identified, 5 
the vCard property mapper 206 retrieves history data 
from the history/association table, and maps and/or for- 
mats the vCard property parameter(s) and field(s) for 
which it is responsible according to the previous map- 
ping history data, thereby maintaining previously made 10 
associations of PIM data between the server iPIM stor- 
age object 114 and a vCard from a client device 104. If 
the synchronization direction is from the server 102 to 
a client device 104 (i.e., the client device's PIM data is 
being updated), the vCard property mapper 206 re- ?5 
trieves PIM data from the history/association table that 
was unmappable to the server iPIM storage object 114 
during a previous synchronization session, processes 
such PIM data as necessary, and adds the processed 
PIM data to the resultant data to be returned at step 920 20 
described below. 

[0073] Upon the completion of mapping and updating 
tasks according to previous mapping history data or if 
no previous mapping(s) is identified at step 906, the 
vCard property mapper 206, at step 908, ascertains 25 
whether there is a previously unmapped (i.e., unsynced) 
property or field(s) for which it is responsible. If not, the 
vCard property mapper 206 advances to step 912 de- 
scribed below. If so, at step 910, the vCard property 
mapper 206 maps and formats the previously un- 30 
mapped property or field(s) using the priority rules, if 
any, present in the PIM specification file 118, default pri- 
ority rules, and/or configuration element values (i.e., in- 
cluding, for example and not limitation, values related to 
size limits, and allowable and/or mapped characters) 35 
with which the mapper 206 was configured during con- 
figuration of the universal mapper 126. Then, the vCard 
property mapper 206 stores the mapping results in the 
history/association table for use in a subsequent syn- 
chronization session. After mapping the previously un- 40 
mapped property or field(s) and storing the mapping re- 
sults, the vCard property mapper 206 proceeds to step 
912 of the mapping method 900. 
[0074] At step 912, the vCard property mapper 206 
decides whether any reverse mapping is possible (i.e., 45 
in the opposite direction of the synchronization session). 
If not, operation of the universal mapper 126 branches 
to step 916 described below. If so, at step 91 4, the vCard 
property mapper 206 calls the appropriate mapping 
method, MapToXX, which maps PIM data in a direction so 
opposite to that of the present synchronization session 
and, if possible, populates PIM data in the reverse di- 
rection into a field(s) or property that has become avail- 
able as a result of the synchronization session. The 
vCard property mapper 206 then loops its operation 55 
back to step 908 described above. 
[0075] At step 916, the universal mapper 126 deter- 
mines whether there are any more properties or fields 



to map. If so, the universal mapper 126 branches oper- 
ation back to step 904 described above. If not, at step 
918, the universal mapper 126 locates all unmapped 
properties and/or fi eld (s), saves the associated PIM da- 
ta in the history/association table, and updates the his- 
tory/association table accordingly to account for and 
persist the unmapped PIM data and allow its return, to 
a client device 104, in a future synchronization session 
which updates the client device 104. Then, at step 920, 
the universal mapper 126 transforms the mapped data 
to the proper format for the direction of the synchroni- 
zation session (i.e., places the mapped data into a UC 
record object or a vCard) and returns the resulting trans- 
formed and mapped data (i.e., resultant data) to the 
sync engine 122 and/or SyncML server 124, as appro- 
priate, for updating of the server iPIM storage object 114 
or communication to the client device 1 04. The universal 
mapper 126 terminates operation in accordance with 
the mapping method 900 at step 922. 
[0076] The previously described methods are utilized 
by the synchronization server system 102 in synchro- 
nizing PIM data between a client device 104 and the 
synchronization server system 102 regardless, for the 
most part, of the synchronization direction. To aid in il- 
lustrating the results of the methods of the preferred em- 
bodiment in a sequence of exemplary synchronization 
sessions in which PIM data is received from a client de- 
vice 104 (i.e., having a type associated with the PIM 
specification file 118 of Figs. 4A and 4B) in the form of 
vCards and is used to update the server's iPIM storage 
object 114, Fig. 1 0A displays a new vCard 1000 which 
is created at the client device 1 04 and which is commu- 
nicated from the client device 104 to the synchronization 
server system 1 02. Upon receipt of the new vCard 1 000, 
the synchronization server system 102 operates ac- 
cording to the methods described herein to identify the 
type of the client device 104 and select the appropriate 
PIM specification file 118 (see Figs. 4A and 4B), to ap- 
propriately configure the universal mapper 126 using 
the selected PIM specification file 118, to map the vCard 
properties to UC fields, and to produce a UC record ob- 
ject which, when stored by the sync engine 122, causes 
the server iPIM storage object 114 to include UC fields 
(i.e., HomeNumber, HomeNumber2, FirstName, Last- 
Name, DisplayName, emaih, and emai!2) having PIM 
data as seen in Fig. 10B. Note that the full text of the 
vCard's note property is saved by the universal mapper 
126 in the UC record's history/association table for re- 
turn to the client device 104 during a later synchroniza- 
tion session in the opposite direction. 
[0077] Subsequently, the client device 104 produces 
a second vCard 1 002 (see Fig. 1 0C) and communicates 
it to the synchronization server system 102. Upon re- 
ceipt of the second vCard 1002, the synchronization 
server system 102 operates according to the methods 
described herein, in a second synchronization session, 
to identify the type of the client device 104 and select 
the appropriate PIM specification file 118 (see Figs. 4A 
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and 4B), to appropriately configure the universal map- 
per 126 using the selected PIM specification file 118, to 
map the vCard properties to UC fields, and to produce 
a UC record object which, when stored by the sync en- 
gine 122, causes the server iPIM storage object 114 to 
include UC fields (i.e., HomeNumber, HomeNumber2, 
FirstName, LastName, DisplayName, emaih, and 
email2) having PIM data as seen in Fig. 10D. Note that, 
as a result of the receipt and processing of the second 
vCard 1002, the UC record of the server iPIM storage 
object 114 now includes an added business telephone 
number and a new note which has been saved in the 
record's history/association table. Note, also, that a sec- 
ond home telephone number was removed as a result 
of the second synchronization session. 
[0078] To aid in illustrating the results of the methods 
of the preferred embodiment for an exemplary synchro- 
nization session in which PIM data is retrieved from the 
server iPIM storage object 114 and used to update the 
client device's dPIM storage object 130, Fig. 11 A dis- 
plays the server iPI M storage object 1 1 4 of Fig . 1 0D after 
changes have been made to add a second home tele- 
phone number, to modify the first email address, and to 
add a home address. After initiation of the synchroniza- 
tion session, the synchronization server system 102 op- 
erates in accordance with the methods described herein 
to identify the type of the client device 104 and select 
the appropriate PIM specification file 118 (see Figs. 4A 
and 4B), to appropriately configure the universal map- 
per 126 using the selected PIM specification file 118, to 
map the UC fields to vCard properties, and to produce 
the vCard 1004 depicted in Fig. 11B. Note that, as a re- 
sult of the "MaxPerContact" configuration element 402 
having a value of two, only the work telephone number 
and the preferred home telephone number were 
mapped to the vCard 1004. Also, note that the note 
property of the vCard 1004 includes the note text re- 
ceived by the synchronization server system 102 in the 
second vCard 1002 (i.e., which updated the UC note 
field that was populated initially with the note text from 
the note property of the new vCard 1000), thereby dis- 
playing the storing and retrieval of the previously un- 
mapped note text from the history/association table by 
the universal mapper 126. In addition, note that the 
vCard 1004 includes an address property not present in 
vCards 1000, 1002, thereby illustrating the mapping of 
previously unmapped PIM data by the universal mapper 
126. 

[0079] It should be understood that the description of 
the preferred embodiment of the present invention is for 
descriptive or exemplary purposes only, and that the ap- 
paratuses and methods of the present invention may be 
utilized in a wired or wireless communications environ- 
ment to map data between two data storage structures 
and/or formats. Also, the communications environment 
may include communication networks or communica- 
tion connections other than the Internet and the use of 
protocols and specifications other than SyncML and 



vCard. Additionally, the present invention's apparatuses 
and methods may be employed in data management ar- 
chitectures other than client/server architectures. In ad- 
dition, the apparatuses and methods of the present in- 

5 vention may be utilized to map any type of data other 
than personal information management data. 
[0080] Whereas this invention has been described in 
detail with particular reference to its most preferred em- 
bodiment, it is understood that variations and modifica- 

10 tions can be effected within the spirit and scope of the 
invention, as described herein before and as defined in 
the appended claims. The corresponding structures, 
materials, acts, and equivalents of all means or step plus 
function elements, if any, in the claims below are intend- 

15 ed to include any structure, material, or acts for perform- 
ing the functions in combination with other claimed ele- 
ments as specifically claimed. 



20 Claims 

1 . A method for mapping data between a data store of 
a server computer and a data store of a client de- 
vice, the method being executed by a computer and 

25 comprising the steps of: 

reading configuration information from a data 
file corresponding uniquely to a particular type 
of client device; 

30 dynamically constructing first programmatic el- 

ements for processing particular types of con- 
figuration information read from the data file; 
executing the first programmatic elements; 
dynamically building second programmatic el- 

35 ements, upon execution of the first program- 

matic elements, for processing data stored in 
the data store of a server computer or in the 
data store of a client device; 
executing the second programmatic elements; 

40 and, 

mapping data, upon execution of the second 
programmatic elements, between the data 
store of the server computer and the data store 
of the client device. 

45 

2. The method of Claim 1 , wherein the method further 
includes a step of dynamically defining a sequence 
for execution of the second programmatic ele- 
ments. 

50 

3. The method of Claim 1 , wherein the method further 
includes a step of, upon execution of a second pro- 
grammatic element, retrieving historical mapping 
information stored during previous mappings, and 

55 wherein the step of mapping data includes a step 
of mapping data between the data store of the serv- 
er computer and the data store of the client device 
according to the historical mapping information. 
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4. The method of Claim 1 , wherein the configuration 
information includes priority rules for mapping data 
between the data store of the server computer and 
the data store of the client device, and wherein the 
step of mapping data includes a step of mapping 
data between the data store of the server computer 
and the data store of the client device according to 
the priority rules. 

5. The method of Claim 4, wherein a priority rule de- 
fines a mapping between one or more data ele- 
ments of the data store of the client device and a 
single data element of the data store of the server 
computer. 

6. The method of Claim 4, wherein a priority rule de- 
fines a mapping between one or more data ele- 
ments of the data store of the client device and one 
or more data elements of the data store of the server 
computer. 

7. The method of Claim 1 , wherein the method further 
includes a step of, upon execution of a second pro- 
grammatic element, storing historical mapping in- 
formation for use in subsequent mappings. 

8. The method of Claim 1 , wherein the method further 
includes the steps of, upon execution of a second 
programmatic element, identifying data from the da- 
ta store of the client device which is unmappable to 
the data store of the server computer, and storing 
the unmappable data for subsequent return to the 
client device. 

9. The method of Claim 8, wherein the method further 
includes a step of, upon execution of a second pro- 
grammatic element, retrieving the unmappable da- 
ta during a subsequent mapping for communication 
to the client device. 

10. The method of Claim 1, wherein the method further 
includes a step of, prior to the step of reading, re- 
ceiving information identifying the data file from a 
plurality of data files which each uniquely corre- 
spond to a different type of client device and include 
respective configuration information associated 
with said different type of client device. 

11. The method of Claim 1, wherein the client device 
includes a device capable of wirelessly communi- 
cating data with the server computer. 

12. The method of Claim 1 , wherein the step of dynam- 
ically constructing includes a step of parsing the 
configuration information read from the data file. 

13. The method of Claim 1, wherein the configuration 
information identifies characters that are non-stor- 



able in the data store of the client device, and 
wherein the step of mapping data includes a step 
of, based at least upon said configuration informa- 
tion, detecting characters that are non-storable in 
5 the data store of the client device. 

14. The method of Claim 13, wherein the configuration 
information identifies respective substitute charac- 
ters for characters that are non-storable in the data 
10 store of the client device, and wherein the step of 
mapping data includes a step of, after the step of 
detecting, replacing non-storable characters with 
respective substitute characters. 

15 15. The method of Claim 1, wherein the configuration 
information identifies the size of a data element al- 
lowed by the data store of the client device. 

1 6. The method of Claim 1 , wherein the method further 
20 includes a step of destructing the first programmatic 

elements and the second programmatic elements 
upon the completion of mapping. 

17. The method of Claim 1 , wherein the method further 
25 includes a step of, prior to the step of mapping data, 

receiving data from the data store of the client de- 
vice in the form of a vCard if data from the data store 
of the client device is being mapped to the data 
store of the server computer. 

30 

18. The method of Claim 1 , wherein the method further 
includes a step of, after the step of mapping data, 
outputting data from the data store of the server 
computer in the form of a vCard if data from the data 

35 store of the server computer is being mapped to the 
data store of the client device. 

19. The method of Claim 1, wherein the method forms 
a part of a synchronization process for synchroniz- 

<o jng data between the data store of the server com- 
puter and the data store of the client device. 

20. A computer program having a plurality of instruc- 
tions executable by a computer for implementing a 

45 method for mapping data between a data store of a 
server computer and a data store of a client device, 
said computer program for directing the computer 
to perform the steps of: 

50 reading configuration information from a data 

file corresponding uniquely to a particular type 
of client device; 

dynamically constructing first programmatic el- 
ements for processing particular types of con- 
55 figuration information read from the data file; 

executing the first programmatic elements; 
dynamically building second programmatic el- 
ements, upon execution of the first program- 
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matic elements, for processing data stored in 

the data store of a server computer or in the 

data store of a client device; 

executing the second programmatic elements; 

and, 

mapping data, upon execution of the second 
programmatic elements, between the data 
store of the server computer and the data store 
of the client device. 

21. The computer program of Claim 20, wherein said 
computer program further directs the computer to 
perform a step of dynamically defining a sequence 
for execution of the second programmatic ele- 
ments. 

22. The computer program of Claim 20, wherein said 
computer program further directs the computer to 
perform a step of, upon execution of a second pro- 
grammatic element, retrieving historical mapping 
information stored during previous mappings, and 
wherein the step of mapping data includes a step 
of mapping data between the data store of the serv- 
er computer and the data store of the client device 
according to the historical mapping information. 

23. The computer program of Claim 20, wherein the 
configuration information includes a plurality of pri- 
ority rules for mapping data between the data store 
of the server computer and the data store of the cli- 
ent device, and wherein the step of mapping data 
includes a step of mapping data between the data 
store of the server computer and the data store of 
the client device according to the plurality of priority 
rules. 

24. The computer program of Claim 23, wherein a pri- 
ority rule of the plurality of priority rules defines a 
mapping between one or more data elements of the 
data store of the client device and a single data el- 
ement of the data store of the server computer. 

25. The computer program of Claim 23, wherein a pri- 
ority rule of the plurality of priority rules defines a 
mapping between one or more data elements of the 
data store of the client device and one or more data 
elements of the data store of the server computer. 

26. The computer program of Claim 20, wherein said 
computer program further directs the computer to 
perform a step of, upon execution of a second pro- 
grammatic element, storing historical mapping in- 
formation for use in subsequent mappings. 

27. The computer program of Claim 20, wherein said 
computer program further directs the computer to 
perform the steps of, upon execution of a second 
programmatic element, identifying data from the da- 



ta store of the client device which is unmappable to 
the data store of the server computer, and storing 
the unmappable data for subsequent return to the 
client device. 

5 

28. The computer program of Claim 27, wherein said 
computer program further directs the computer to 
perform a step of, upon execution of a second pro- 
grammatic element, retrieving the unmappable da- 

10 ta during a subsequent mapping for communication 
to the client device. 

29. The computer program of Claim 20, wherein said 
computer program further directs the computer to 

*5 perform a step of, prior to the step of reading, re- 
ceiving information identifying the data file from a 
plurality of data files which each uniquely corre- 
spond to a different type of client device and include 
respective configuration information associated 

20 with said different type of client device. 

30. The computer program of Claim 20, wherein the cli- 
ent device includes a device capable of wirelessly 
communicating data with the server computer. 

25 

31. The computer program of Claim 20, wherein the 
step of dynamically constructing includes a step of 
parsing the configuration information read from the 
data file. 

30 

32. The computer program of Claim 20, wherein the 
configuration information includes characters that 
are non-storable in the data store of the client de- 
vice, and wherein the step of mapping data includes 

35 a step of, based at least upon said configuration in- 
formation, detecting characters that are non-stora- 
ble in the data store of the client device. 

33. The computer program of Claim 32, wherein the 
40 configuration information includes respective sub- 
stitute characters for characters that are non-stora- 
ble in the data store of the client device, and wherein 
the step of mapping data includes a step of, after 
the step of detecting, replacing non-storable char- 
ts acters with respective substitute characters. 

34. The computer program of Claim 20, wherein the 
configuration information includes information iden- 
tifying the size of a data element allowed by the data 

50 store of the client device. 

35. The computer program of Claim 20, wherein said 
computer program further directs the computer to 
perform a step of destructing the first programmatic 

55 elements and the second programmatic elements 
upon the completion of mapping. 

36. The computer program of Claim 20, wherein said 
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computer program further directs the computer to 
perform a step of, prior to the step of mapping data, 
receiving data from the data store of the client de- 
vice in the form of a vCard if data from the data store 
of the client device is being mapped to the data 5 
store of the server computer. 

37. The computer program of Claim 20, wherein said 
computer program further directs the computer to 
perform a step of, after the step of mapping data, 10 
outputting data from the data store of the server 
computer in the form of a vCard if data from the data 
store of the server computer is being mapped to the 
data store of the client device. 

f5 

38. The computer program of Claim 20, wherein said 
computer program forms a part of a synchronization 
computer program for synchronizing data between 
the data store of the server computer and the data 
store of the client device. 20 

39. A system for mapping data between a data store of 
a server computer and a data store of a client device 
belonging to a particular type of client devices, said 
system comprising: 25 

a plurality of configuration data files having con- 
figuration information, wherein each configura- 
tion data file corresponds to a respective type 
of client device; and, 30 
a computer program operable to map data be- 
tween a data store of a server computer and a 
data store of a client device belonging to a par- 
ticular type of client devices, said computer pro- 
gram residing on a media and being executable 35 
by a processing unit, said computer program 
being dynamically configurable upon execution 
using configuration information from a configu- 
ration data file of said plurality of configuration 
data files associated with said particular type of *o 
client devices. 

40. The system of Claim 39, wherein said computer pro- 
gram is operable to dynamically construct a plurality 

of first executable programmatic elements for 45 
processing particular types of configuration infor- 
mation based at least upon configuration informa- 
tion from said configuration data file associated with 
said particular type of client devices. 

50 

41 . The system of Claim 40, wherein said computer pro- 
gram is operable, in response to execution of a first 
executable programmatic element of said plurality 
of first executable programmatic elements to dy- 
namically construct a plurality of second executable 55 
programmatic elements for processing data stored 

in said data store of said server computer or in said 
data store of said client device. 



42. The system of Claim 41 , wherein said computer pro- 
gram is operable to determine a sequence of exe- 
cution of said plurality of second executable pro- 
grammatic elements and to cause execution of said 
plurality of second executable programmatic ele- 
ments in said sequence. 

43. The system of Claim 41 , wherein a second execut- 
able programmatic element of said plurality of sec- 
ond executable programmatic elements is operable 
to retrieve historical mapping information from a pri- 
or mapping session and to maintain mapping iden- 
tified by said mapping information while mapping 
data between said data store of said server compu- 
ter and said data store of said client device. 

44. The system of Claim 41 , wherein a second execut- 
able programmatic element of said plurality of sec- 
ond executable programmatic elements is operable 
to retrieve a priority rule governing the mapping of 
data between said data store of said server compu- 
ter and said data store of said client device, and is 
further operable to map data between said data 
store of said server computer and said data store 
of said client device according to said priority rule. 

45. The system of Claim 41 , wherein a second execut- 
able programmatic element of said plurality of sec- 
ond executable programmatic elements is operable 
to store a mapping association made between said 
data store of said server computer and said data 
store of said client device as historical mapping in- 
formation for use in a subsequent mapping session. 

46. The system of Claim 41 , wherein a second execut- 
able programmatic element of said plurality of sec- 
ond executable programmatic elements is operable 
to identify data from said data store of said client 
device which is unmappable to said data store of 
said server computer, and to store said unmappable 
data for subsequent return to said client device. 

47. The system of Claim 46, wherein a second execut- 
able programmatic element of said plurality of sec- 
ond executable programmatic elements is operable 
to retrieve said unmappable data and to return said 
unmappable data to said client device. 

48. The system of Claim 39, wherein said configuration 
data file associated with said particular type of client 
devices includes information identifying a character 
which is non-storable in said client device. 

49. The system of Claim 39, wherein said configuration 
data file associated with said particular type of client 
devices includes information identifying a substitute 
character for a character which is non-storable in 
said client device. 
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50. The system of Claim 39, wherein said configuration 
data file associated with said particular type of client 
devices includes information identifying a size limit 
for data of said data store of said client device. 
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FIG. 3 

<PimSpecConfig> 
<Handset> 



116 



306 



<Man>Nokia<7Man> * 
<Mod>9210</Mod> 
<Swv>256</Swv> 310 
<Hwv>00</Hwv> 
<=Def>true</De1> 
<Nam>Nokia9210<yNam> 



</Handset> 
<Handset> 



<Man>Nokia</Man> 308 
<Mod>123456</Mod> 

*Swv>256</Swv> ^ 3^ 

<Hwv>1.0<:/Hwv> 
<Def>true</Def> 316 
<Oem>Nokia</Oem> 304 
<Nam>Nokia9210</Nam> ^ 

«^Handset> 

<handset> 

<Man>Nokia</Man> 
<Mod>6185i</Mod> ^ 314 
<Fwv>1.0</Fvw> <r ^- 312 
<Swv>1.0</Swv> 
<Hwv>1.0</Hwv> 

Oef>tnje</Def> 3Q4 

<Nam>Nokia6l85fc/Nann> 
</Handset> 
<Handset> 



<Man>Ericsson</Man> *" 
<Swv>Ria</Swv> 
<Hwv>R1A</Hwv> - 9n 
<Def>true</Def> ^ u ^ 318 
<Usr>EricssonR520/R201 </Usr> 

<Nam>EricssonR520m</Nam> 
</Handset> 

<Handset> _^--~306 

<Man>Ericsson</Man> 
<Def>true</Def> 

<Usr>EricssonT39m/R20l</Usr> 304 

<Nam>Er«cssonT39m</Nam> 
</Handset> 

<PirnSpecConfig> ~" 
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FIG. 5 

500 

<Devlnf> 
<VerDTD> 

1 -0 5Q2A 
</VerDTD> / 
<Man> «r 

NOKIA ^ S02B 

</Man> 
<Mod> 

123456 . 502D 

</Mod> 
<SwV> 

256 502C 
</SwV> / 
<HwV> <r 

1.0 
</HwV> 
<DevlD> 

IMEI : 1505945177105413 

</DevlD> 
<DevTyp> 
phone 
</DevTyp> 
</Devlnf> 



FIG. 4A ^ us 

^ 402, 404 
<PimSpec> 402,406 

<VCardTypes> ^ 402A 

<MaxContacts>200</MaxContacts> *^ 4Q20 
<MaxVCardsize>l024</MaxVCardsize> ^ 

<TEL> « — — 408A 

<MaxPerContact>2</MaxPerContact> 
<PimSpecType>POLY<yPimSpecType> 
<PriorityRules>STD</PriorityRules> 



<UCSubType> — 402F 

402 G > <BusinessFax>WORK</Bus»nessFax> „ — 4K)A 

<BusinessFax>FAX</BusinessFax> « — 41 qb 
</UCSubType>^__ 4 q2h - 
<UCType> 



<Business>WORK</Business> 
<Business>VOICE</Business> 
<Home>HOME</Home> 
<Home>VOICE</Home> 
<Mobiie>CELL</Mobile> 
<Mobile>VOlCE</Mobile> 
</UCType> _ 
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FIG. 4B 



<UCType> 



<Business>WORK</Business> 
<Home>HOME</Home> 
<Mobile>CELL</Mobile> 



</UCType> 
</TEL> 



408B 



<ADR> *~ 

<SlotCount>2</SlotCount> 

<UCSubType> 

<HomeAdr>HOME<yHomeAdr> 
<BusinessAdr>WORK</BusinessAdr> 

</UCSubType> 

<UCType> 

<AdrType>NULL</AdrType> 

</UCType> 

</ADR> 408D 



<FamilySteeUmit>lOO</FamilySizeLimit> 
<6ivenSizeUmit>l00</GivenSizeLimit> 
<AdditionalSizeUmit> 1 00</AdditionalSizeLimit> 
<PrefixSizeUmit>lOO</PrefixSizeUmit> 
<SuffixSizeUmit>l0O</SuffixSizeLimit> 

<VaiidA|phabet>45-46,48-57,64-90,95-95,97-l22</ValidAlphabet> 
<MappingChars>95:47</MappingChars> 

<W> 408C 



<EMAIl_> 4 

<SlotCount>2</SlotCount> 

</PimSlots>l</IPimSlots> 

<SizeUmiT>l47</Si2et-imit> 

<DefaultPref>FALSE</DefaultPref> 

<VCARDParm>lNTERNET<A/CARDParm> 



<SlotCount>2</SlotCount> 
<URLType>NULL</URLType> 

<UCSubType> 

<Persona!HomePage>HOME</Persona)HomePage> 

</UCSubType> 
</ADR> 
<A/CardTypes> 
</PimSpec> 




<SizeLimit>256</SizeLimit> 
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FIG. 6 
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FIG. 7A 



( START ) 



RECEIVE Devlnf DTD DATA FROM 
CLIENT DEVICE 
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CREATE SET OF ENTRIES HAVING 
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AS Devlnf DTD DATA 
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FIG. 7C 
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FIG. 8 
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FIG. 9C 
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FIG. 10A 



BEGIN: VCARD / 

VERSIONS. 1 

REV:19990101T101717Z 

N :lastname;firstname 

FN: firstname lastname 

TEL;HOME:88888888 

TEL;HOME;PREF:4444444 

EMAlL;INTERNET;HOME:emaii@myhome 

EMAIL;INTERNET;WORK;PREF:email@work 

NOTE;X-EPOCCNTMODELFIEL.DLABEL=Notes:this is a note of something else 
END: VCARD 



HomeNumben 4444444 <r 
HomeNumber2: 88888888 
FirstName: firstname 
LastName: lastname 
DisplayName: firstname lastname 
email 1 : emaiiffivuork 
email2: email® rnvhome 

full text of NOTE property is saved off to be returned on an update 



BEGIN:VCARD ^ 
VERSlON:2.1 ^ 
REV:19990101T101717Z 
N:lastname;firstname 
FN: firstname lastname 
TEl_;WORK:7777777777 
TEL;HOME;PREF:4444444 
EMAIL;INTERNET;HOME:email@myhome 
EMAIL;lNTERNET;WORK;PREF:email@work 

NOTE;X-EPOCCNTMODELFIELDl_ABEL s Notes:changed from the initial card 
END: VCARD 



FIG. 10B 




FIG. 10C 



1002 
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FIG. 10D 



114 



BusinessNumber- added: 7777777777 
HomeNumber - no change: 4444444 
HomeNumber2 - removed 
FirsiName - no change: firstname 
LastName - no change: lastname 
DisplayName - no change: firstname lastname 
emaill : emaili5)vwork 

email2 : email® myhome 

full text of NOTE property is saved off to be returned on an update 



114 

FIG. 11A y 

BusinessNumber - nochange : 7777777777 

HomeNumber2 - added: 5555555555 (not mapped, we have a limit of 2) 

HomeNumber - no change : 4444 444 

FirstName - no change : firstname 

LastName - no change: lastname 

DisplayName - no change: firstname lastname 

email! _ modified: email© newworKplace 

email2 - no change: email{5)mvhome 

HomeAddress - added 

Street : 101 NextToTheHighway 

City : Unameit 

State : MA 

PostalCode : 01730 

Country : United States of America 



FIG. 11B 

BEGIN: VCARD 

VERSION:2.1 

REV:1 9990101T1 017172 

N: lastname;firstname 

FN: firstname lastname 

TEL;WORK:7777777777 

TEL;HOME;PREF:4444444 

EMAIL;INTERNET;HOME:email@myhome 

EMAlL;lNTERNET;WORK;PREF:email@newworKplace 

NOTE;X-EPOCCNTMODELFlELDLABEL=Notes:changed from the initial card 

ADR;HOME:;;I01 NextToTheHighway;Unameit;MA;0l730;United States of America 

END: VCARD 
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